Tulpa.info - guide-discussion

Cat_SG | Shadow System

I thought Ranger would submit his possession guide first, but then I was in the mood to type and I got it knocked out in a few hours.

since this is a discussion channel, may I make a suggestion?

7:35 AM

Im adhd as fuck so im gonna type it now but feel free to reject it Your guide mentions asking lots of questions about how the object looks/feels etc, I read in a guide or something once that a good way to make sure you cover your bases is to pretend you're writing about it and trying to "paint a picture" for a reader who has never seen the object before. It might be a helpful tip for people who find themselves running out of ways to describe the object, or don't know where to start

If it's from another guide, I don't want to plagiarize ^^' Assuming it isn't from another guide... The concept is similar, but after setting up a theme of one question at a time, I'm not sure if I can break from that without going off-topic. If I introduced this, it would have to be pretty early on and having a paragraph dedicated to an example could throw things off when the rest of the guide is the bit by bit approach. Alternatively, I also wonder if I could say "This is like pretending to write about an object and describing to a reader who has never seen this object before" in the summary of the skill part. Although, I'm not sure if that's what you had in mind.

I dont remember if it was from a guide

I'm paraphrasing it heavily tho so even if it was it wouldnt be plagiarism imo

Paraphrasing can still be plagiarism. I know these are tulpa guides, but I don't like the idea of taking someone else's idea without crediting them (hence why I link Chupi's and Nikodemo's guides because this concept isn't original to begin with)

1:14 PM

I can try to look for it, maybe it will pop up

if memory serves it was some sort of tip/trick for visualisation

I forgot Reisen wrote a visualization guide

While this guide recommends writing details about your tulpa down, the author doesn't say write like you're explaining it to someone who never saw it before: https://community.tulpa.info/topic/4893-kakelis-guide-to-better-visualization/

Lumi: Was Reisen's a guide, or just a long Tips & Tricks? (edited)

1:32 PM

It was just a useful activity for people like me to use, not a big deal, we don't consider it a guide

It was a Tips and Tricks guide, but it was cool to see

1:33 PM

I think it was a cool concept

It was cool that she went out of her way to come up with that just for me (and anyone else who benefited from it)

1:34 PM

Our system's usually much more averse to making Submissions

For us it's less about being averse and more about us taking a long time. It took me awhile to write it and then make changes once I got feedback

1:37 PM

God knows how long Ranger spent on his possession guide so far, and he doesn't consider it done yet

I'm glad I grabbed that broken link and fixed it https://community.tulpa.info/topic/38-mental-image-rendering-guide/ For anyone who has a guide to Tulpa.info- we almost lost Linkzelda's guide to a Google Doc, please upload loose parts and 3rd party documents as attachments! (edited)

Are attachments safer than external links?

Yes

Did they survive the previous forum transition?

I think they did? That's a good question

Lumi: I go back and forth on whether I trust my own hosting services or the forum's for things (edited)

1:39 PM

So far, Imgur is one of the only sites whose embeds have survived a full decade, while things like Google will last forever if you never screw with your account's files, or get copyrighted or something (edited)

1:39 PM

Though if the forum transition kept old attachments, I guess I can trust it

I can't think of something I attached before the forum transition...

Just check like any art thread

1:40 PM

from many years ago

True

the first two things I see are a broken deviantart link, and a working imgur link, from 2014 lol

1:41 PM

https://community.tulpa.info/topic/9032-dusks-form/

Dusk's Form

I had originally built Dusk Runes form off of my MLP OC. pic is the attachment

1:41 PM

This appears to have saved from 2015

1:42 PM

I guess attachments are trustworthy, then, assuming other file types also transferred

1:43 PM

At the very least, attaching your file in your forum post leaves preservation in our hands, that's something we'd take note to back up before changing forum softwares or such

1:43 PM

Whereas it seems people just can't help but delete their various accounts every few years..

Yeah... I really hope the Felights didn't sabotage their guide material come to think of it...

Lumi: Mmm, I'm a HUGE proponent for preservation of most things on the internet, but I also respect someone's right to intentionally remove what was theirs to some extent (edited)

1:45 PM

If they wanted their submissions gone, officially they should be removed, while unofficially people could keep backups

It doesn't look like they did. I'll create back-ups just in case

1:49 PM

Wait, I'm looking at the wrong thing. This is a survey not a guide

1:50 PM

Their creation guide is okay

It looks like their guides are okay. One had a few broken links and I'm uploading back-ups

If anyone else notices a guide or article that's hosted by a third party service, please let me know

I have a guide to servitors I wrote for my baby witch server, I'd like some feedback on it if someone is willing

Sure

https://magivulpes.blogspot.com/2020/12/basic-servitor-creation.html

Basic Servitor Creation

What is a Servitor? A servitor is a type of thoughtform that does not have any free will and is not sentient. They are essentially a kin...

2:57 PM

I broke down "types" and a general guide

This guide is a lot shorter than I expected it to be

People think in a lot of different ways, I didn't want to be too restrictive in case it caused someone to "stall" you know? Like in math class when you just cant grasp a concept the way its being taught

There are some people who write guides with the philosophy of a "One size fits all" approach, but I don't think it's the best way to approach guide creation. The problem I have with this approach is it seems to suppress the guide writer to share their experiences because it would no longer apply to everyone or the guide writer assumes their experiences must apply to everyone. While I think a one size fits all approach can be somewhat achievable, you have to incorporate other people's experiences and do a lot of research to pull it off, and even then it's going to be slanted with your bias. I think it's better to focus on what you learned and how you got there. If it doesn't apply to everyone, that's okay, they're not you. I think it's also worth pointing out how your experiences impacted your thought process, especially if that isn't relevant to other people.

So I should edit to share examples from my own experiences?

3:07 PM

in summary

I think this guide would benefit from having more examples. They don't have to be exact personal experiences if you want to keep the guide in 3rd person, but I think the examples should be based on your experiences. For instance, here's a short paragraph from your guide:

Fragment Servitor
    A fragment servitor is only capable of one highly specific function. It generally has no nuance to it whatsoever but is instead used to provide nuance/support to simple and complex servitors.

What would be an example of a fragment servitor? I'm assuming you have created a fragment servitor or at least thought of creating one, if you did what was it designed for and what did it do? (edited)

An example in my view would be the servitor I created as part of Tahanis' pain response

3:17 PM

It caused the grey blob to turn crimson in response to input from another servitor, which detected pain. It served no other purpose other than to change the colour of the blob

3:17 PM

the pain response itself would be a simple servitor

3:17 PM

bc I made it from several fragments

If I'm following correctly, a fragment would be "turn crimson" and the simple servitor would be the whole system put together (the pain response servitor)? (edited)

a fragment would be input>turn crimson

3:23 PM

and the simple servitor would be {[detect stimulus>send output]>[detect input>turn crimson]>[detect colour change>send output]>[(detect input>send output)>(detect input>send output outside of program)]>[detect input>self stimulate]>[detect self stimulation>turn grey]} (edited)

3:23 PM

and that's the entire simple servitor for the pain response

3:27 PM

well its the beta

3:27 PM

the final version includes programming that adds a glow that changes intensity based on the intensity of the pain

3:28 PM

and some routines that change the shade of red a little depending on the type of pain

3:29 PM

physical pain is a bright crimson and sensory under/overstimulation is a very dark red

3:29 PM

I've toyed with the idea of adding patterns of red so it doesn't have to repeat its programming to express output for simultaneous types of pain (edited)

3:30 PM

But I haven't gotten around to developing that yet

a fragment would be 
input>turn crimson
and the simple servitor would be
{[detect stimulus>send output]>[detect input>turn crimson]>[detect colour change>send output]>[(detect input>send output)>(detect input>send output outside of program)]>[detect input>self stimulate]>[detect self stimulation>turn grey]}
and that's the entire simple servitor for the pain response

All of this is a good example of what a fragment is vs a simple servitor. While you can make up a hypothetical servitor if you wanted too, this alone is the right idea for an example. Since it seems like there's a hierarchy of complexity, it may be easier to think of one complex servitor example and break the servitor down into its simple and fragment parts. (I don't think I'm doing this right) if I had a GUI servitor (complex), the simple parts would be the layout settings, the button to show the body scan, etc. The body scan servitor we have is made up of fragments [input>anxiety]>[return image]. In this case, I would start with the simple fragment for the body scanner, then explain the body scanner, and then explain the GUI where the body scanner is accessible via a command. I hope I didn't make that too confusing, I'm not an expert in this approach to servitor creation (edited)

I think my article is best suited to those with autism and adhd, because both of those mindsets tend to break things down further and further and I have both. I think that's why I wrote it the way I did

There's nothing wrong with the hierarchy part, I think that's fine. When I read the guide, I'm having trouble understanding the [input>(sensory experience)] > [do>(this)] approach without an example. Even though you provide a definition for a fragment servitor, I can't quite wrap my head around the concept without an example.

Ah ok

3:45 PM

I'll put some thought into more examples and edit the guide

3:45 PM

can I ping you to read it over again later?

Sure! I like this guide, I think it's an interesting approach to servitor creation

thank ouo

3:46 PM

I think I should add a disclaimer that my guide isnt the only way, just the way I've chosen to break it down for others

I'm aware of one other servitor guide, and I think that's okay! In fact, you shouldn't post the same ideas someone else proposed unless you're adding to the conversation (which you are)

there's also a bit of pronoun inconsistency in your bio, @A Gaggle of Giggles

🝀

there's also a bit of pronoun inconsistency in your bio, @A Gaggle of Giggles

I dont see how

11:06 PM

@A Gaggle of Giggles

ah ok

11:07 PM

fixed

I like the idea of an upvote/star system for guides. I think something like that could do a lot of good(I even remember considering that as an option as some point before forgetting about it)

Lumi: I think a system where we simply act like every single user is a GAT member would be best. IE, everyone can vote, by posting and including approval or disapproval (you don't have to do either, you can just comment or give criticism etc. as now), with guides being approved and moved from Submissions to Guides after some point (edited)

2:36 AM

A GAT role to manually move the guides once they have X number of approvals (and more importantly, when the OP is not clearly still trying to improve their guide) would still be necessary, or we could just have existing mods do it

2:36 AM

Other than their vote as a user if they want, they wouldn't have any "judging" power though

2:37 AM

I don't think any system where we can't see why people are upvoting/downvoting is good for quality control. Upvotes do not reflect quality.

2:38 AM

(that said, I don't think any requirements for your vote/approval are necessary, you could just post "I like it! Approved", though obviously common etiquette would say give at least a short reason for why you chose to dis -approve it) (edited)

2:40 AM

Upvote culture is terrible

2:40 AM

But if the guides are for the community, then there shouldn't be anything wrong with letting them be approved by the community

I would agree, but there are two problems to this system. The first is people don't have a lot of time on their hands and writing reviews is work. Not everyone can write a review, at best people will take turns. Every round will be completely unpredictable in what feedback will be given. Additionally, if there is no check on the quality of these reviews, there is no accountability for being polite or accurate in your feedback. The second problem is the review system itself was hurting guide submissions. I think this could be easily solved by making the GAT process optional or applying some other system (such as a place for people to submit rough drafts before submitting), but it won't matter because the GAT has dissolved.

Lumi: 1) How is an anyone-can-one-click-upvote system any more reliable than one where people need to care enough to at least comment? And again, I didn't say there had to be any requirement on what they posted, just "I like it! Approved" (or whatever word/phrase we use) would be enough, as long as the upvote/approval is in post form - in-depth review or criticism totally optional (as is voting itself, you could just leave a comment/advice and not vote) 2) The whole point of all of this is to make sure only guides worth reading get displayed... If you're not confident what you wrote can even stand up to the community itself, you clearly aren't going to write a guide for the community (edited)

4:19 AM

The point of changing the system is so that guide writers don't feel like they're going up against a specific group of approvers

4:19 AM

The community itself is the bare minimum they should have to get majority approval from, obviously

The way I see it - it's much less of a problem if the community self-reviews, especially if those reviews are given less credence by default. People don't want to throw their guide at a literal review board - but I'd be surprised if people didn't upload guides with the notion that some rando peers on the internet wouldn't agree with them. I see no point at all in an upvote system. None whatsoever - especially if there is no planned rejection method. And the last thing I'd want is guides with low-engagement and good quality being buried. At least with upvotes and downvotes there is some level of actual moderation. I'm with Luminesce in general on this one I think a basic community review process that doesn't require in-depth description, but requires a post, would be ideal - and it allows for more in-depth reviews to continue without the impression that those reviews are some sort of gatekeepy judgement from on high. Perhaps a review timeframe, and if a guide can get a majority approved score during that time it is approved? (edited)

Lumi: I didn't even think about how slowly gathering the bare minimum approvals over like 5 years might be a problem (edited)

4:35 AM

Maybe... require the guide-poster to be active/give the OK to move their submission, as part of the process

4:36 AM

Which is already kind of important for those who want to keep improving their submissions based on advice from the community first

I shared my thoughts to Luminesce's post here: https://community.tulpa.info/topic/16757-community-feedback-survey/?do=findComment&comment=333058 As for gatekeeping- gatekeeping is built in to any approval and disapproval process, including the GAT. The point is to gatekeep "bad" guides and let in the "good" ones. If anyone disagrees with someone's idea of what a "bad guide" is, they may be accused of gatekeeping if they believe their reasoning isn't sound. Since the GAT can only judge guides about subjective experiences based on what the GAT members subjectively think of tulpamancy experiences, gatekeeping is going to be an issue regardless. I think the worst gatekeeping comes from a lack of open-mindedness or a desire to tear down a certain philosophy because it's different from what you think, but it can be hard to sift out things in the gray area. For example, parallel processing- is it bad advice to have it in a guide, especially since it's controversial and it may or may not exist? I think the ultimate solution is to have a large enough GAT so unusual biases don't taint the review process too much and have the community step up when the GAT's ideology doesn't match the community's. However, there's no way to prevent gatekeeping without censorship of some kind and have a system that approves and disapproves guides. A community review in a time frame would mean only a set number of people will review- and I bet you those that bother to review will probably do it more often- thus creating an informal (and disorganized) GAT (edited)